The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
In conventional database systems, users access their data resources in one logical database. A user of such a conventional system typically retrieves data from and stores data on the system using the user's own systems. A user system might remotely access one of a plurality of server systems that might in turn access the database system. Data retrieval from the system might include the issuance of a query from the user system to the database system. The database system might process the request for information received in the query and send to the user system information relevant to the request.
The issuance of queries and retrieval of results has limits in ease of use and efficiency for users. Accordingly, database systems allow developers to write software applications in the form of executable code that provide and interface between users and the database. In some cases software development tool kits or packages are made available to assist developers in writing software that is reliable and does not impact the database. Application programming interfaces (APIs) are sometimes provided to allow certain tasks to be automated and to further protect the database from unauthorized software actions.
In a traditional implementation, executable code is authored by a programmer on behalf of a host organization and then executed within that host organization. In such an environment, the host organization may have a “live” or a “production” environment in which executable code is released and serves to fulfill the business objectives of the organization. In such a traditional implementation, the host organization may also utilize a “test” environment or a “sand-box” environment that closely replicates the production environment, but in which unreleased code can be tested for quality and compliance without negatively impacting actual customers of the host organization that are utilizing the production environment.
Before the software is released debugging utilities provide tools to allow the developer to step through the code either line by line, or progressing up to a designated point, at which execution is stopped. This allows the programmer to, for example, analyze the detailed program flow, the status of variables, including their contents and input/output (IO) operations to datastores, databases, memory, or to files, and so forth.
Such debugging utilities require that execution of the codebase being tested be halted, stopped, or paused at specified points as designated by the programmer for further analysis. This interferes with the use of the database by users. In addition, because the debugging utility allows the developer to run the code one step at a time, the code is executed very slowly. This can block access by user for a long time. While debuggers can be operated during off-peak usage times, this is inconvenient for programmers and may not be possible when the user group spans several time zones.
The limits on use and the limited information made available in a step-by-step execution on a debugging utility make software development difficult. Sandbox testing provides helpful results but may not reveal bugs that result with many users and large datasets and with interactions with other programs.
Accordingly, it is desirable to provide techniques enabling an execution stack pane of a simulation interface having hierarchical tree of nodes of operations and an execution log pane coupled to the execution stack pane to improve the ease of analyzing the performance of software applications that might execute on a database system.